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COMMUNICATION PROTOCOL FOR CONTENT ON DEMAND SYSTEM WITH 
CALLBACK TIME 

CROSS-REFERENCES TO RELATED APPLICATIONS 
[01] This application claims priority from U.S. Provisional Application 
5 No. 60/243,925, entitled "SYSTEM FOR CONTENT DELIVERY OVER A COMPUTER 
NETWORK," filed on October 26, 2000 and U.S. Provisional Application 60/263,087, 
entitled "SYSTEM FOR SECURELY DELIVERING ENCRYPTED CONTENT ON 
DEMAND WITH ACCESS CONTROL," filed January 18, 2001. These applications are 
incorporated herein by reference for all purposes. This application is also related to the 

10 following U.S. Non provisional applications, U.S. Patent Application No. 08/420,710, now 
U.S. Patent No 5,627,892, entitled "DATA SECURITY SCHEME FOR POINT-TO-POINT 
COMMUNICATION SESSIONS," filed April 19, 1995; U.S. Patent Application No. 

, entitled "SYSTEM FOR DENYING ACCESS TO CONTENT 

GENERATED BY A COMPROMISED OFF LINE ENCRYPTION DEVICE AND FOR 

1 5 CONVEYING PERIODICAL KEYS FROM MULTIPLE CONDITIONAL ACCESS 

SYSTEMS," filed July 3, 2001; U.S. Application No. , entitled "SYSTEM 

FOR SECURING ENCRYPTION RENEWAL DEVICE AND FOR REGISTRATION 
AND REMOTE ACTIVATION OF ENCRYPTION DEVICE," filed July 3, 2001; U.S. 
Patent Application No. , entitled "SYSTEM FOR DENYING ACCESS TO 

20 CONTENT GENERATED BY A COMPROMISED OFF-LINE ENCRYPTION DEVICE 
AND FOR CONVEYING PERIODICAL KEYS FROM MULTIPLE CONDITIONAL 

ACCESS SYSTEMS," filed ; U.S. Patent Application No. July 3, 2001, 

entitled "SYSTEM FOR SECURELY DELIVERING PRE-ENCRYPTED CONTENT ON 
DEMAND WITH ACCESS CONTROL," filed July 3, 2001, all of which are hereby 

25 incorporated by reference in their entirety as if set forth in full in the present invention, for 
all purposes. 

BACKGROUND OF THE INVENTION 

30 [02] The present invention relates generally to the field of content 

communication and more specifically to a system for communicating video content on 
demand through a communication network having a communication protocol with callback 
time. 
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[03] Conventional systems for delivering video content on demand to 
subscribers are becoming well known. VOD (video on demand) is an interactive service in 
which content (e.g., video) is delivered to a subscriber over a point-to-point network (e.g., a 
cable system) on an on demand basis. A subscriber may order and receive programming 
5 content at any time, without adhering to a predefined showing schedule. The subscriber is 
often provided VCR-like motion control functions, such as pause (freeze frame), slow 
motion, scan forward, and slow backward. The subscriber is typically allowed multiple 
views of a purchased program within a time window, e.g., 24 hours. VOD mimics (or 
exceeds) the level of control and convenience of rental video tapes. 

10 

Entitlement Management Messages 

[04] EMMs (Entitlement Management Messages) are control messages 
that convey access privileges to subscriber terminals. Unlike ECMs (Entitlement Control 
Messages) (discussed below) which are embedded in transport multiplexes and are 

15 broadcast to multiple subscribers, EMMs are sent unicast-addressed to each subscriber 
terminal. That is, an EMM is specific to a particular subscriber. In a typical 
implementation, an EMM contains information about the periodical key, as well as 
information that allows a subscriber terminal to access an ECM which is sent later. EMMs 
also define the tiers for each subscriber. With reference to cable services, for example, a 

20 first EMM may allow access to HBO™, ESPN™ and CNN™. A second EMM may allow 
access to ESPN™, TNN™ and BET™, etc. 

Entitlement Control Messages 

[05] In a conditional access system, each content stream is associated with 
25 a stream of ECMs (entitlement control messages) that serve two basic functions: (1) to 

specify the access requirements for the associated content stream (i.e., what privileges are 
required for access for particular programs); and (2) to convey the information needed by 
subscriber terminals to compute the periodical key(s), which are needed for content 
decryption. ECMs are transmitted in-band alongside their associated content streams. 
30 Typically, ECMs are cryptographically protected by a "periodical key" which changes 

periodically, usually on a monthly basis. The monthly key is typically distributed by EMMs 
prior to the ECMs, as noted above. 
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Encryption 

[06] In a cable system, carrier signals are broadcast to a population of 
subscriber terminals (also known as set-top boxes). To prevent unauthorized access to 
service, encryption is often employed. When content is encrypted, it becomes unintelligible 
5 to persons or devices that don't possess the proper periodical key(s). 

[07] Disadvantageous^, for VOD, real-time encryption poses much 
greater cost and space issues. A medium-sized cable system may have, for example, 50,000 
subscribers. Using a common estimate of 10% peak simultaneous usage, there can be up to 
5000 simultaneous VOD sessions during the peak hours. A typical encryption device can 

10 process a small number of transport multiplexes (digital carriers). Over 300 such real-time 
encryption devices will be needed to handle the peak usage in the example system. Such a 
large amount of equipment not only adds significantly to the system cost, but also poses a 
space requirement challenge. 

[08] One solution to the aforementioned problem is disclosed in co- 

L 5 pending related U. S . Patent Application No . , entitled SYSTEM FOR SECURELY 

DELIVERING PRE-ENCRYPTED CONTENT ON DEMAND WITH ACCESS 
CONTROL, filed July 3, 2001, which is hereby incorporated by reference in its entirety. In 

U.S. Patent Application No. , a system is disclosed that encrypts content offline 

(typically before the content is requested by the user) before it is distributed to point-to- 

20 point systems such as cable systems. The system allows content to be encrypted once, at a 
centralized facility, and to be useable at different point-to-point systems. Advantageously, 
the pre-encrypted contents in the present invention have indefinite lifetimes. The system 
periodically performs an operation called ECM retrofitting, enabling the content to be 
useable in multiple systems and useable multiple times in the same system. The amount of 

25 data being processed during ECM retrofitting is very small (on the order of several thousand 
bytes). There is no need to reprocess the pre-encrypted contents. This is a significant 
advantage, as several thousand bytes represent only a tiny fraction of the size of a typical 2- 
hour video program, which is about 3 gigabytes (3,000,000,000 bytes) in size. 

[09] A first aspect of U.S. Patent Application No. system includes 

30 a content preparation system (CPS) for pre-encrypting the content offline to form pre- 
encrypted content; an encryption renewal system (ERS 104) for generating entitlement 
control messages (ECMs) that allow the pre-encrypted content to be decryptable for a 
designated duration; and a conditional access system (CAS). Conventionally, the CAS 
controls a population of set-top boxes using a randomly generated category key. Only with 
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possession of the category key can the pre-encrypted content be decrypted by the set-top 
boxes. The category key is initially forwarded to the ERS 104 which thereafter generates an 
ECM containing information regarding the category key. The process or requesting and 
generating ECMs for pre-encrypted content is known as ECM retrofitting. 
5 [10] After a VOD system receives pre-encrypted content and an associated 

encryption record, the system must receive appropriate retrofitted ECMs from the ERS 104 
before the content is offered to consumers. The ECMs enable the pre-encrypted content to 
be decrypted. In this fashion, the ERS 104 can be connected to multiple VOD systems for 
which ECM retrofitting is performed. However, in order to perform ECM retrofitting, the 

10 VOD systems must submit a request to the ERS 104. Disadvantageously, without such a 
mechanism, it would be relatively difficult to initiate ECM retrofitting for the pre-encrypted 

content. Another disadvantage of U.S. Patent Application No. , is that in some 

instances, each VOD server may employ a protocol version different or incompatible with 
the ERS 104 system version. In such cases, it necessary to employ a system allowing 

15 interoperability between all of the system components. A further disadvantage relates to the 
fact that ERS 104 is connectable to multiple VOD systems. Consequently, ERS 104 may 
become overwhelmed with multiple simultaneous requests, since the VOD systems must 
contact ERS 1 04 for the retrofitted ECMs . 

[11] Therefore, there is a need to resolve the aforementioned 
B " 20 disadvantages and the present invention meets this need. 

SUMMARY OF THE INVENTION 
[12] A first aspect of the present invention is a communication protocol 
for a content on demand system with callback time. The protocol which is partly based on 

25 XML (extensible markup language) permits transactions between an ERS (encryption 

renewal system) and one or more video on demand (VOD) systems. After receiving pre- 
encrypted content and an associated encryption record, a VOD system must receive 
appropriate retrofitted ECMs from the ERS before the content is offered to consumers. The 
ECMs enable clients of the VOD system to access the pre-encrypted content. To initiate 

30 retrofitting and transmit the ECMs, the VOD system employs the present invention to 

communicate with the ERS which also responds using the present communication protocol.. 
Furthermore, a callback time specifying when the VOD system should contact the ERS is 
included in the response to the VOD system. 
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[13] The communication protocol includes the steps of receiving, by the 
encryption renewal system, a request transaction document having a first format from the 
video on demand system. In one aspect, the first format is XML, a publicly available meta 
mark-up language. The protocol further includes parsing the request transaction document 
5 to retrieve data from the request transaction document; and generating an object request 
code in a second format for processing by encryption renewal system, the object request 
code based on the data in the request transaction document. In a further aspect, the second 
format is in Java™, a product of Sun Microsystems, San Jose, Ca. 

[14] Responsive to processing of the request object code, other steps 
10 include generating a response object code having the second format; converting the 
response object code to a response transaction document having the first format; and 
forwarding the response transaction document to the video on demand system. 

[15] According to another aspect of the present invention, the request 
transaction document contains an encryption record, a data structure having one or more 
1 5 periodical keys for accessing the pre-encrypted content. 

[16] According to another aspect of the present invention, the protocol 
includes the step of parsing the request transaction document to determine a protocol 
version of the request transaction document, wherein the request object code is partly based 
on the protocol version. 
20 [17] According to another aspect of the present invention, the request 

transaction document is a request to retrofit an entitlement control message for permitting 
clients of the video on demand system to access the pre-encrypted content. 

[18] According to another aspect of the present invention, the response 
transaction document is a response to the request to retrofit the entitlement control message. 
25 [19] According to another aspect of the present invention, in a 

communication system having an encryption renewal system coupled to one or more on 
demand servers, a method by the encryption renewal system for allowing the on demand 
server to callback the encryption renewal system is disclosed. The method includes 
receiving a first request to retrofit an entitlement control message; retrofitting the 
30 entitlement control message to allow access to pre-encrypted content; and generating a first 
response having the entitlement control message which is retrofitted, wherein the response 
further comprises a first callback time specifying a time for the video on demand system to 
contact the encryption renewal system. 
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[20] According to another aspect of the present invention, the method 
consists of receiving a second request to retrofit prior to the first callback time; and 
generating a response having a second callback time that invalidates the first callback time. 

[21] Advantageously, the present invention is flexible, and is supported 
5 using Internet based open standards solutions such as XML, XML Schemas or DTD 
(document type definition), XML Parsers, XML document builders, and w3c DOM 
(document object model) all freely available for use. Furthermore, using the callback 
mechanism, VOD system clients are kept updated, if the clients callback as scheduled, thus 
avoiding loss of service due to outdated ECMs. 

10 

BRIEF DESCRIPTION OF THE DRAWINGS 
[22] Fig. 1 shows a system architecture for delivering encrypted content to 
a subscriber in accordance with a first embodiment of the present invention. 

[23] Fig. 2A is a block diagram of a network having one or more VOD 
1 5 systems and an encryption renewal system for the purpose of illustrating XML transaction 
flow between both components. 

[24] Fig. 2B is a block diagram of network of Fig. 2A depicting the 
logical flow of data between VOD system and ERS . 

[25] A further understanding of the nature and advantages of the present 
20 invention herein may be realized by reference to the remaining portions of the specification 
and the attached drawings. Reference to the remaining portions of the specification, 
including the drawings and claims, will realize other features and advantages of the present 
invention. Further features and advantages of the present invention, as well as the structure 
and operation of various embodiments of the present invention, are described in detail 
25 below with respect to the accompanying drawings. In the drawings, the same reference 
numbers indicate identical or functionally similar elements. 

DETAILED DESCRIPTION OF THE INVENTION 
[26] According to first aspect, the present invention is a communication 
30 protocol for a content on demand system with callback time. The protocol which is partly 
based on XML (extensible markup language) permits transactions between an ERS 
(encryption renewal system) and one or more video on demand (VOD) systems. After 
receiving pre-encrypted content and an associated encryption record, a VOD system must 
receive appropriate retrofitted ECMs from the ERS before the content is offered to 
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consumers. The ECMs enable clients of the VOD system to access the pre-encrypted 
content. To initiate retrofitting and transmit the ECMs, the VOD system employs the 
present invention to communicate with the ERS which also responds using the present 
communication protocol.. Furthermore, a callback time specifying when the VOD system 
5 should contact the ERS is included in the response to the VOD system. 

[27] The communication protocol includes the steps of receiving, by the 
encryption renewal system, a request transaction document having a first format from the 
video on demand system. In one aspect, the first format is XML, a publicly available meta 
mark-up language. The protocol further includes parsing the request transaction document 
1 0 to retrieve data from the request transaction document; and generating an object request 
code in a second format for processing by encryption renewal system, the object request 
code based on the data in the request transaction document. In a further aspect, the second 
format is in Java™, a product of Sun Microsystems, San Jose, Ca. 

[28] Responsive to processing of the request object code, other steps 
15 include generating a response object code having the second format; converting the 
response object code to a response transaction document having the first format; and 
forwarding the response transaction document to the video on demand system. 

[29] Fig. 1 is a system architecture 100 for delivering encrypted content to 
a subscriber in accordance with a first embodiment of the present invention. 
20 [30] Among other components, system architecture 100 comprises a 

content preparation system (CPS) 102 for pre-encrypting content, video on demand (VOD) 
system 108 storing encrypted programs for distribution to subscribers on an on demand 
basis, conditional access system 1 10 for controlling one or more keys granting access to 
pre-encrypted content, an encryption renewal system 104 ERS 104 accepting requests from 
25 the video on demand system to generate new entitlement control messages for pre- 
encrypted content, a distribution network 112 for distributing content, and an interactive 
network 1 14 providing two-way interaction between the subscriber and the content system. 
Although not shown, one of ordinary skill in the art would realize that other components 
and arrangement for achieving the various functionalities of system architecture 100 are 
30 possible. For example, VOD system may be coupled directly to CAS 110 and 

functionalities consolidated in both components since both components are typically located 
within a cable system head end. 

[31] In operation, the VOD system 108 is installed to provide VOD to 
subscribers. Before going live, VOD system 108 goes through a registration process with 



7 



the ERS 104. This establishes the identity of the VOD system 108 to the ERS 104 so it can 
produce proper and appropriate responses specific to that VOD system installation. Once 
VOD system 108 registration is complete, content may be added to VOD system 108 and 
made available to subscribers. Clear content (a), such as a movie, originates from a content 
5 provider and begins its entry to the VOD at CPS 102. Here, the clear content is encrypted 
using an Off Line Encryption System (OLES) (not shown), which pre-encrypts the content 
in preparation for delivery by VOD system 108. The OLES also generates an encryption 
record associated with the encrypted content. Note that VOD system 108 may keep the 
encryption record with the pre-encrypted content at all times as it identifies the content for 
1 0 later processing and decryption within VOD system 108. 

[32] Once the clear content is encrypted at the OLES, the resulting pre- 
encrypted content and associated encryption record are delivered to VOD system 108 for 
storage on the local server. Advantageously, multiple VOD systems may be coupled to 
CPS 102 such that content is encrypted once and distributed to the systems. VOD system 
15 1 08 is responsible for keeping the pre-encrypted content and associated encryption record 
together. Before the pre-encrypted content may be requested or viewed by subscribers in 
their homes, VOD system 108 obtains suitable Entitlement Control Messages (ECMs) from 
the ERS 104. VOD system 108 submits an ECM request to ERS 104, containing the 
encryption record (c) for the desired pre-encrypted content. 
20 [33] ERS 1 04 responds with the proper ECMs, an ERS 1 04 

synchronization number, and a callback time. The ECMs are created specifically for the 
particular pre-encrypted content and particular point-to-point system within which VOD 
system 108 operates, and for a particular time period. The ECMs encrypt content using a 
key (typically periodical) provided by each conditional access system (CAS 1 10 in the 
25 present case) controlling the set-top boxes. VOD system (108) inserts the received ECMs 
into the streams along with the pre-encrypted content whenever it is spooled out to a 
subscriber. The ECMs are inserted into the streams with the content. 

[34] It should be observed that ECMs returned to VOD system 108 by 
ERS 104 are valid and usable with the pre-encrypted content only for a limited time— the 
30 exact time, determined by CAS 1 1 0, is not predictable in advance. Thus, the callback time 
returned with the ECMs indicates the time by which VOD system 108 should check with 
the ERS 104 to see if ECMs for all pre-encrypted content may be updated. When VOD 
system 108 receives the callback time it should be stored and tracked against the current 
time. If the callback time is reached and the VOD system 108 has not contacted ERS 104 in 
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the intervening time, then VOD system 108 attempts to contact the ERS 104 even if it has 
no new ECM requests to fulfill. 

Content Preparation System (CPS) 
5 [35] In Fig. 1 , content preparation system (CPS) 102 is a centralized 

facility for preparing contents according to the requirements of the VOD system (VOD) 108 
and those of the Conditional Access system (CAS) 110. CPS 102 encodes content in a 
format (e.g., MPEG-2) suitable for storage on video servers and for distribution to the 
subscriber terminals. For content that is already available in the suitable format, this 
10 encoding step may be unnecessary. CPS 102 also functions to encrypt digitally encoded 
content according to the specifications of CAS 110. 

[36] The encryption process involves generating one or a series of 
periodical keys. As part of the encryption process, the periodical keys, or the parameters 
used in their generation, are saved in a data structure called an encryption record. The 
1 5 encryption is protected by encryption to prevent unauthorized access to the keys. CPS 102 
may package encrypted programs with the associated encryption records, which may 
additionally contain useful but nonessential information about the content. Such 
information may include program title, identification of the program assigned by different 
parties, encoding parameters, program length, etc. CPS 102 may serve multiple cable 
20 systems or multiple point-to-point systems. The content preparation process described 
above produces encoded and encrypted content ready for distribution to VOD systems 
across a diverse geographic area. Some potential methods of content file distribution are via 
physical media, network file transfer, or satellite file transfer. 

[37] Although not shown, CPS 1 02 includes an OLES (off line 
25 encryption) device for performing the aforementioned functionality. The OLES uses one or 
more non-real-time, or offline, encryption devices to encrypt content. A given OLES 
generates program-specific periodical keys that are used to encrypt content. The OLES is 
protected by physical security including physical access control and secure packaging. The 
OLES includes functions such as accepting encryption control provisioning parameters 
30 from the ERS 104 including cryptographic information to support content encryption; 
selecting one or more periodical keys based on the encryption control parameters and 
system configuration which keys are used for encrypting the program content; generating an 
encryption record, which contains information about the keys used to encrypt the content. 
This record itself is encrypted to maintain the security of the encryption record; encrypting 
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the program content using the chosen keys; and providing the encrypted content and the 
encryption record to the CPS, for subsequent transfer to at least one VODS. 

[38] Typically, an OLES is registered and authorized by the ERS 104 
prior to having ability to perform encryption operations. ERS 104 provides a removable 
disk containing authorization and configuration parameters for the OLES such data being 
processed during initial setup. As noted, as part of the encryption process, the periodical 
keys or the parameters used in their generation, are saved by the OLES in a data structure 
called an encryption record. The OLES is capable of processing an MPEG content in an 
off-line manner whereby the raw content has been completely encoded and is obtainable 
from a server (VOD or other server) or has been placed onto the OLES system. One of 
ordinary skill will realize that the above guidelines are exemplary and other embodiments 
having different guidelines are possible. 

Video On Demand System (VOD system) 

[39] VOD system 108 comprises one or more video servers adapted for 
video on demand applications. The servers store encrypted programs for distribution to 
subscribers on an on demand basis. Thereafter, the pre-encrypted programs are routed and 
streamed to the authorized subscribers. In addition, VOD system 108 accepts purchase 
requests from subscriber terminals, and validates and authorizes such purchase requests as 
appropriate. In some instances, after a purchase request is approved, the VOD purchases 
may be temporarily stored until requested by the subscriber. 

[40] VOD systems generally are well known in the art and need not be 
described in detail. 

Conditional Access System (CAS) 

[41] As noted, content system 100 includes a conditional access system 
(CAS) 110. CAS 110 permits access to pre-encrypted content by subscriber terminals by 
provisioning them with EMMs, and generating ECMs for non-VOD services. Other 
functions of CAS 1 10 include controlling real-time encryption devices in the cable system; 
reporting the (scheduled) occurrence of monthly key changes to the encryption renewal 
system (described below), and transmitting cable system-specific cryptographic parameters 
(e.g., monthly keys) to the encryption renewal system to enable ECM retrofitting. CAS 
systems are well known in the art and may comprise off the shelf items. In addition, one of 
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ordinary skill in the art such as a programmer can develop code as may be necessary to 
accommodate the present invention. 

Billing System (BS) 

[42] BS 106 interfaces with both VOD system 1 08 and CAS 1 1 0 to 
provide the following functions: (1) accepting subscription and service change requests 
from subscribers; (2) maintaining subscriber account information; (3) billing subscribers; 
(4) interfacing with VOD system 108 to provide the latter with subscriber authorization 
status, and to collect video on demand purchase information from the latter; and (5) 
providing subscriber authorization status, service and event definition information, and to 
collecting purchase information. 

Encryption Renewal System (ERS 104) 

[43] As shown in Fig. 1, ERS 104 interfaces with CPS 102, VOD system 
108 and CAS 110. ERS 104 enables pre-encrypted content to be distributed to VOD system 
108 and other authorized VOD system entities while enabling access control within each 
CAS 1 10. The ERS 104 performs ECM renewal (ECM retrofitting) in synchronization with 
category epoch rollover events occurring within each participating CAS 1 10. A category 
epoch is the nominal period during which a category key used by CAS 1 10 to protect the 
distribution of program keys is in effect. 

[44] Encrypted content from the CPS is unusable until an initial ECM 
"renewal" operation is performed. To make the content usable for the first time, VOD 
system 108 contacts ERS 104 to obtain the first set of ECMs. Henceforth, ECM renewal is 
performed periodically to keep valid ECMs associated with each content title on VOD 
system 108. ERS 104 functions include: generating encryption control parameters for 
initializing OLES devices, communicating with the CAS in different point to point systems, 
accepting requests from a VOD system to generate ECMs for pre-encrypted content, 
computing retrofitted ECMs, sending retrofitted ECMs to the requesting VODS, and 
maintaining databases of appropriate parameters. ERS 104 may also interface with VOD 
system 108 to forward information about (scheduled) monthly key changes to VOD system 
108. 

[45] ERS 104 is implementable using hardware, software or a 
combination of both. For example, a number of coding languages such as Java™ or servers 
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like Apache Group's Apache™ and operating environments such as Windows NT™ may be 
employed in the present invention. 

Distribution Network 

[46] Distribution Network 1 12 is a network that distributes signals to all 
or a subset of the subscribers in the system. Distribution Network 112 may comprise hybrid 
fiber-coax (HFC) technology, for example. In an HFC network, for example, broadcast 
signals are distributed from the head end (central office) to a number of second level 
facilities (distribution hubs). Each hub in turn distributes carriers to a number of fiber 
nodes. In a typical arrangement, the distribution medium from the head-end down to the 
fiber node level is optical fibers. Subscriber homes are connected to fiber hubs via coaxial 
cables. At some level of distribution facility (hub, fiber node, or other distribution 
facilities), video on demand carriers are broadcast to a subset of the subscriber terminal 
population served by the distribution facility. This typically occurs at the fiber node level. 
This arrangement allows the reuse of video on demand carrier frequencies, say across fiber 
nodes, because different fiber nodes broadcast different video on demand carriers to the 
subscribers they serve. 

Interactive Network 

[47] Interactive network 1 14 is communicably coupled to VOD system 
108 and set top population 120 to provide a two-way communication capability between 
the subscriber terminals and the VOD system 108. Interactive Network 1 14 may share 
some of the physical infrastructure of Distribution Network 1 12. 

Renewing ECMs 

[48] ECM retrofitting is the process of generating ECMs for pre-encrypted 
contents so that they are useable in different cable systems and despite monthly key 
changes. It is performed by a server hosted in ERS 104, which is a secure environment. 
Content is encrypted prior to a request from a subscriber terminal. ERS 104 provisions the 
offline encryption devices in CPS 102 with encryption control parameters, which, among 
other functions, enable ERS 104 to retrieve information from encryption records generated 
by the CPS. This provisioning need be done only infrequently, or possibly just once. It 
need not be done with every ECM retrofitting request from the VOD system 108. 
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[49] Next, an encryption record of parameters for encrypting the content is 
generated. VOD system 108 establishes a secured connection to ERS 104. The 
communication protocol for establishing the secured connection is described below. To 
make a pre-encrypted program usable in a particular system for a particular period, VOD 
system 108 sends the encryption record to ERS 104 which checks the authorization status of 
the requested content from VOD system 108. If the authorization check fails, ERS 104 
terminates the session. Otherwise, the process continues. ERS 104 generates one or more 
ECMs for the pre-encrypted program using the monthly key associated with the cable 
system (and possibly other parameters required by the CAS). The ECM(s) are created in 
such a way that they will be valid until the monthly key of the target system changes again. 
ERS 104 sends the retrofitted ECM(s) and pre-encrypted content to the subscriber via VOD 
system 108. 

[50] Fig. 2A is a block diagram of a network 200 for illustrating XML 
transaction flow between one or more VOD systems 108 and ERS 104. As shown, 
communication between VOD system 108 and ERS 104 is via the Internet 204 and a 
firewall 206. To request ECM retrofitting, VOD system 108 prepares and forwards an 
XML document to ERS 104 which is responsible for generating the appropriate ECMs, as 
further described with reference to Fig. 2B. 

[51] Fig. 2B is a block diagram of network 200 of Fig. 2A depicting the 
internal data between VOD system 108 and ERS 104. As shown, at block 210, a request 
transaction document having a first format is generated and forwarded to ERS 104. 

[52] Preferably, the first format is XML, although one of ordinary skill in 
the art will realize that other formats consistent with the spirit and scope of the present 
invention may be employed. XML is a meta-language for defining other structural 
languages such as HTML (Hypertext markup language) for example. Further, XML uses a 
DTD or schema to constrain the definition of the protocol between VOD system 108 and 
ERS 104. In essence, XML permits the definition of a baseline grammar for describing 
transaction requests from VOD system 108 to the ERS 104 and transaction responses from 
the ERS 104 to VOD systems. Advantageously, off-the-shelf XML parsers (block 212) 
used by applications for understanding the protocol grammar are employed. 

[53] At block 212, the request transaction document is parsed using an 
XML parser/document generator. 

[54] At block 214, parsing results in determining the protocol version 
employed by VOD system 108. As used herein, a parser is a program, frequently part of a 
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compiler, that receives input in the form of sequential source program instructions, 
interactive online commands, markup tags, or some other defined interface and breaks them 
up into parts (for example, the nouns (objects), verbs (methods), and their attributes or 
options) that can then be managed by other programming (for example, other components in 
a compiler). 

[55] It should be noted that the protocol supports multiple simultaneous 
versions. The version of the protocol is indicated within an XML document by a <VerX.X> 
tag (see example below), where X.X is the protocol version currently supported and 
assigned to a particular VOD System to use. Although not always the case, the <VerX.X> 
is typically the first child element of ERSPayload. The XML Schema contains the current 
<VerX.X> or <VerX> tag to support the latest protocol version as well as previous 
<VerX.X> tags for backward compatibility. The version indicated by X.X can take any 
form for subsequent protocol versions. 

[56] When the request transaction document is parsed, various data are 
retrieved in addition to obtaining the protocol version. For example, the request transaction 
document contains an ECMRequest element containing encryption record data for the pre- 
encrypted content. The ECMRequest element consists of a single element called 
EncryptionRecord, containing such pertinent data as the pre-encrypted content title, 
encryption time, offline encryption device, etc. 

[57] At block 2 1 8, a request obj ect code having a second format and 
corresponding to the determined protocol version (and data) is generated. Preferably, the 
second format is Java™ although one of ordinary skill in the art will realize that other 
formats within the spirit and scope of the present invention are applicable. 

[58] At block 220, the request object code is processed and a 
corresponding response object code having the second format is generated. The response 
object code generated depends on the transaction requested by VOD system 108. For 
example, if ECM retrofitting is requested, the response object code appropriate for ECM 
retrofitting is generated. 

[59] At block 222, the response object code is converted to a response 
transaction document having the first format (e.g. XML) as shown at block 224, and 
forwarded to VOD system 108 as shown at block 224. Among other data, the response 
transaction document contains a callback time, specifying a time for the video on demand 
system to contact the encryption renewal system. 
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[60] In this manner, the present invention facilitates communication 
between one or more video on demand systems coupled to an encryption renewal system. 
This is particularly the case when the transaction concerns ECM requests and responses. 
Advantageously, the present invention is flexible, and is supported using Internet based 
5 open standards solutions such as XML, XML, DTDs or Schemas, XML Parsers, XML 
document builders, and w3c DOM (document object model) SAX all freely available for 
use. Furthermore, using the callback mechanism, VOD system clients are kept updated, if 
the clients callback as scheduled, thus avoiding loss of service due to outdated ECMs. 

10 The Callback Time Mechanism and the ERS Synchronization Number 

[61] All valid ERS Transaction Responses to the VOD System contain a 
Callback Time specified in Coordinated Universal Time (UTC) which is a standard XML & 
ISO time format. The format for UTC will be the following: 
CCYY-MM-DDThh:mm:ssZ 
15 [62] "CC" represents the century, "YY" the year, "MM" the month and 

"DD" the day. The letter "T" is the date/time separator and "hh", "mm", "ss" represent hour, 
minute and second respectively. The format for time must be specified using Coordinated 
1 Universal Time (UTC). A "Z" will immediately follow this representation to indicate 

Coordinated Universal Time without time zone adjustment. The Callback Time indicates 
" 20 the next time by which VOD System 108 should contact the ERS 104. In other words — if 
the Callback Time passes before VOD System 108 sends an ERSPayload transaction 
request to ERS 104, then VOD System 108 is required to send a request to ERS 104. 

[63] In normal operation, new content will be added to VOD System 108 
at regular intervals; thus, VOD System 108 sends ECM Requests to ERS 104 at regular 
25 intervals as well. If VOD System 108 sends an ECM Request to ERS 104 before the 
previous Callback Time was reached, then a new Callback Time will be received in the 
ERSPayload transaction response. This new Callback Time invalidates the previous 
Callback Time. However, if no new content is added to the VOD System and the last 
received Callback Time is reached, then the VOD System is required to contact the ERS. 
30 [64] In this case, VOD System 108 requests the ERS Synchronization 

Number using ERSPayload with only the Sender element included, as there is no need to do 
an ECM Request. The ERSPayload transaction response sent by ERS 104 contains a new 
Callback Time for VOD System 108, and the current ERS Synchronization Number, the 
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latter indicating the lifetime of ECMs. Hence, the implication is that VOD system 108 need 
not call ERS 104 unless it has specific requests to fulfill. The scheduling of the Callback 
Time provided to VODS clients by the ERS is done at the time of the VODS request, and is 
managed dynamically. This allows both the callback schedules and loading to be changed 
5 at any time. 



Use of HTTP POST 

[65] ERS 104 protocol messages are valid XML documents, with a single 
ERSPayload root element and a structured hierarchy of tags describing the possible 

10 operations and data. An XML document is enclosed using elements or tags. A root or child 
element is the opening and closing tags in which all other elements are enclosed. As noted 
below, every logical operation begins with VOD system 108 sending an ECM request 
specified using an ECMRequest XML element. More information regarding version 1.1 of 
the HTTP protocol may be obtained by referring to RFC (Request for Comments) 2616. 

1 5 [66] To send an ERSPayload/HTTP request, VOD system 108 performs 

an HTTP POST to a well-known URL associated with ERS 104. Every logical operation 
begins with VOD system 108 sending a request. ECM requests are specified using an 
ECMRequest XML element, and ECM responses are specified using an ECMResponse 
element. For ERSPayload/HTTP, the ECMRequest is typically sent in an HTTP post, and 

20 the ECM response to that request is typically sent in the HTTP Response to that POST. 
Thus, ECM Request/Response pairs always map directly to HTTP POST/Response pairs. 
The following is a pseudo-code representation of the protocol to illustrate where the use of 
the HTTP POST would occur. An ERSPayload for both request and response corresponds 
to a single HTTP POST/Response transport level transaction. 

25 

(1) VODS ERS (HTTP POST): 

<ERSPayload> 

<Verl.0> 

30 

<ECMRequest> Contents of request... </ECMRequest> 

</Verl.0> 
</ERSPayload> 
35 (2) VODS ERS (HTTP Response to the POST): 
<ERSPayload> 

<Verl.0> 

<ECMResponse> Contents of ECM information... </ECMResponse> 

40 

</Verl.0> 
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</ERSPayload> 

[67] The ERS 1 04/VODS interface protocol allows multiple requests or 
responses to be sent in a single payload message. This allows round trips to be minimized 
5 whenever possible. For example, a VOD system with eight titles to be retrofitted can send 
all eight ECM requests and receive all eight ECM responses in a single HTTP 
POST/Response communication. The following is sample HTTP syntax that may be used 
to communicate XML transactions from VOD system 108 to the ERS 104: 

1 0 POST /VODSTransaction HTTP/1 . 1 
HostERS.COM 

Authorization:Basic dm9kczpwYXNzd28yZA== 
From: admin@vodsysl .vodcompany.com 
Content-Type: application/x-www-form-urlencoded 
15 Content-Length: 30 

xmldata=ValidXMLDocument 

VOD System/ERS 104 Interface Protocol Specification 
20 [68] The tables in the following subsections represent the protocol 

transactions that flow between the ERS 104 and one or more VOD Systems 108. Element 
tables have five columns and attribute tables. An attribute is a characteristic of an element 
that can be changed. The attribute tables have four columns that use some combination of 
the following column headings: Element Name: represents the name of the field or XML 
25 element pair. For instance, if the Element Name specified were "ERSPayload", then the 
corresponding XML element pair would be "<ERSPayload></ERSPayload>" (or the 
shorter form for the pair, "<ERSPayload/>"). Attribute Name: represents the name of the 
XML attribute that is associated with the specified element. For instance, if the element 
specified was "ERSPayload" and if the Attribute Name were "payloadld", then the 
30 corresponding XML would be written as "<ERSPayload payloadld- '123 12"> 
</ERSPayload>". 

[69] Direction Flow: indicates the direction flow of transaction data 
between sender and receiver. The transaction data is the most meaningful for the recipient, 
even though the protocol may require the element or attribute to be present in either 
35 direction of transaction flow. The XML elements or attributes from VOD system 108 to the 
ERS 104 that are required to be sent are indicated as VODS -> ERS. Elements or attributes 
from the ERS 104 to VOD system 108 that are required to be sent are indicated as ERS 
VODS. Element or attributes information required in either direction is indicated as: VODS 
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<-> ERS. Required?: indicates whether the current XML element or attribute is required to 
be present in its current context. The root element, ERSPayload, envelops all transactions 
that flow between the ERS 104 and VOD Systems. The ERSPayload element may be 
required when delivering transactions to the ERS 104 from VOD Systems and when 
5 delivering responses from the ERS 104 to VOD Systems. 

[70] Other columns are, Element Value: This column indicates a type 
and/or value (or a range of values) that are associated with Element Name or Attribute 
Name. In some cases there may only be a note that indicates how Element Name or 
Attribute Name can be used. In other cases, "None" will be the designation when there are 
10 no values associated with Element Name or Attribute Name. Nested Elements?: this 

column heading only applies to Element Name when Element Name contains other nested 
elements. Nested elements for the protocol specification are given by the XML schema 
definition. 

[71] The element names of the embodiment shown in the tables represent 
1 1 5 the XML elements that would be used to construct a well-formed XML document. A well- 
formed document is one created following certain XML rules. Otherwise, the document is 
useless. A completed XML document represents one transaction message. The Verl .0 
element under the ERSPayload element sent from VOD Systems to the ERS 104 may 
contain eight or more ECM requests and an implicit query for the next ERS 104 
20 Synchronization Number and Callback Time that corresponds to the requesting VOD 
System. 



Element Name 


Direction Flow 


Required? 


Element Value 


Nested 
Elements? 


VER1.0 


VODS <-> ERS 


No 


Only one Verl.O 
element per 
ERSPayload element 


Yes 


ERSStatus 


VODS o> ERS 


No 


Can have 0 . . n of 
this element present 


Yes 



Table 1 



[72] The ERSPayload element has five attributes shown in Table 2. The 
25 ERSStatus element, in Table 2 above, would appear in a response from the ERS to VODS 
indicating to the VODS that the input XML transaction document was incomprehensible to 
the ERS. One or more ERSStatus elements could appear in the response from ERS to 
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VODS to adequately describe the exceptional error condition. Verl.O and ERSStatus are 



mutually exclusive. 



Attribute Name 


Direction Flow 


Required? 


Attribute Value 


xmlns 


VODS ^ ERS 


Yes 




xmlns:xsi 


VODS <-> ERS 


Yes 


http://ww.w3.org/2000/10/XMLScriema-iristarice 


xsi: schemaLocation 


VODS <o> ERS 


Yes 




payloadld 


VODS <-> ERS 


No 


String (25 character maximum) 



Table 2 



[73] The xmlns attribute identifies the target namespace for the XML 
5 transaction document. ERS 104 echoes the same value (received from the VODS) for this 
attribute in the reply to VOD system 108. The xmlns:xsi attribute identifies the XML 
Schema instance namespace. ERS 104 echoes the same value (received from the VODS) 
for this attribute in the reply to VOD system 108. The xsi: schemaLocation attribute 
identifies the ERSPayload namespace and a URL path to an XML schema that defines 
1 0 ERSPayload. The ERS 1 04 will echo the same value (received from the VODS) for this 
attribute in the reply to VOD system 108. Note that there is an intentional space between 
value pairs for this attribute. The payloadld is an optional String attribute that allows VOD 
system 108 to insert a value for transaction tracking purposes. ERS 104 echoes the same 
value (received from the VODS) for this attribute in the reply to VOD system 108. The 
1 5 maximum length of this field is 25 characters. 

[74] The following table lists the elements of the Verl .0 message element: 



Element Name 


Direction Flow 


Required? 


Element Value 


Nested 
Elements? 


Sender 


VODS ERS 


YES 


No content. See Table 6 
for attributes of the Sender 
element 


No 


ECMRequest 


VODS ERS 


NO 


Note: Can use this field to 
make eight or more 
ECMRequests 


Yes 


ECMResponse 


ERS -» VODS 


No 


Note up to eight or more 
ECMResponses may be 
received 


Yes 


ERSSynchNumber 


ERS VODS 


Yes, if payload 
is OK 


integer value from 0 to 
255; value wraps back to 0 


No 


CallbackTime 


ERS -> VODS 


Yes, if payload 
is OK 


UTC Time 


No 


ERSStatus 


ERS VODS 


Yes, if an error 
occurred; No 
otherwise 


Note: Can have more than 
one ERSStatus per 
ERSTransactionResponse 
message 


No 



Table 3 
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[75] Presently, the ECMRequest element can be used up to eight times 
within the context of an ERSPayload/Verl.O message. Each ECMRequest element 
represents one ECM retrofit request for a single VOD title. When a request is unsuccessful, 
5 the ERSPayload/Verl .0 message contains the appropriate error status messages using the 
ERSStatus element. A typical transaction error that might occur would be that the incorrect 
VODId was specified during a transaction request. The Verl .0 element under the 
ERSPayload tag from the ERS 104 to the VODS may have one or more ECMResponses 
while the ERSSynchNumber and CallbackTime is included when the original payload 

1 0 message was successfully parsed. 

[76] ERSSynchNumber is an integer value from 0 to 255 (wraps back to 
0) that indicates whether or not VOD system 108 needs to submit ECM retrofit requests for 
ECMs that have become outdated. VOD system 108 decides this by comparing the new 
ERSSynchNumber, received in the Verl.O response, to the one it is currently maintaining. 

1 5 If the one received is newer, then VOD system 1 08 must submit ECM retrofit requests for 
all titles associated with all previously maintained ERSSynchNumbers. CallbackTime 
informs VOD system 108 of the next time it should log into the ERS 104 to see if the 
VODS ERSSynchNumber has changed. CallbackTime is specified as Coordinated 
Universal Time (UTC). Note that the ERSSynchNumber and CallbackTime are returned 

"20 only if the ERSPayload transaction request was successful. In other words, if VOD system 
108 successfully logged into the ERS 104, then the ERSSynchNumber and CallbackTime 
are returned to VOD system 108. The Sender element has three attributes, defined in Table 
4 below: 

[77] The following table lists the attributes of the Sender element: 

25 



Attribute Name 


Direction Flow 


Required? 


Attribute Value 


id 


VODS o ERS 


Yes 


string; "ers" reserved for the ERS 


password 


VODS <-» ERS 


Yes 


string; password is "n/a" when sent 
from ERS to VODS 


role 


VODS <-> ERS 


Yes 


Either "vods" or "ers" 



Table 4 



[78] The id attribute uniquely identifies VOD system 1 08 to the ERS 1 04. 
This value is assigned to VOD Systems by the ERS 104 during VOD System enrollment. 
The value "1" identifies the ERS 104 and is sent in the id attribute in replies from the ERS 
30. 1 04 to VOD Systems. The password attribute corresponds to the id attribute and allows the 
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VOD system 108 to log into the ERS 104 and submit ECM retrofit requests. This value is 
assigned to VOD Systems by the ERS 104 during VOD System enrollment. The value 
"n/a" is sent in the password attribute for replies from the ERS 104 to VOD Systems. 

[79] The role attribute indicates the role of the sender. For instance, if 
5 VOD system 108 sends ECM retrofitting requests to the ERS 104, the value for the role 
attribute is "vods". Conversely, if the ERS 104 sends a response to VOD system 108, then 
the value of the role attribute would be "ers". 

[80] The following table lists the elements of the ECMRequest element: 

10 



Element Name 


Direction Flow 


Required? 


Element Value 


Nested 
Elements? 


EncryptionRecord 


VODS ERS 


Yes 


Only one per 
ECMRequest 


Yes 



Table 5 



[81] The body of the ECMRequest element consists of a single element 
called EncryptionRecord. The following table lists the elements contained in the 
EncryptionRecord element: 
15 



Element Name 


Direction Flow 


Required? 


Element Value 


Nested 
Elements? 


TitleldCode 


VODS ERS 


No 


String 


No 


ContentTitle 


VODS ^ ERS 


No 


String 


No 


EncryptionTime 


VODS -» ERS 


Yes 


timelnstant 


No 


OLESId 


VODS ERS 


Yes 


long 


No 


Label 


VODS ERS 


Yes 


integer 


No 


EncryptionMode 


VODS ^ ERS 


Yes 


integer 


No 


EncryptedDataVersion 


VODS -> ERS 


Yes 


integer 


No 


EncryptedDataBlock 


VODS ERS 


Yes 


Base64 encoded binary 
value 


No 



Table 6 



Information Sent From ERS 104 to VOD System During Transaction 
Response 

20 [82] The ECMResponse element contains one ECMRecord and, 

optionally, an ERSStatus element when the ECM retrofit completes successfully for a given 
title. If the retrofit fails for a particular title, then an ECMResponse contains both the 
TitleldCode (if provided in the ECM request) and ERSStatus elements. See Table 7 and 
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Table 8 for more information on the contents of the ECMResponse element for successful 
and unsuccessful ECM retrofits. The following table lists the elements of the 
ECMResponse element when the transaction is successful: 



Element Name 


Direction Flow 


Required? 


Element Value 


Nested 
Elements? 


ECMRecord 


ERS ^ VODS 


Yes 


Note: Only one per 
ECMResponse 


Yes 


ERSStatus 


ERS -> VODS 


No 


Note: May have more 
than one ERSStatus 
per ECMResponse 


No 



Table 7 



[83] The following table lists the elements of the ECMResponse element 
when the retrofit for a given title is unsuccessful: 



Element Name 


Direction Flow 


Required? 


Element Value 


Nested 
Elements? 


TitleldCode 


ERS -> VODS 


Yes, if provided in 
the original retrofit 
request 


String 


No 


ERSStatus 


ERS -> VODS 


Yes 


Note: May have more 
than one ERSStatus per 
ECMResponse 


No 


Table 8 

[84] The following table lists the elements of the ECMRecord element: 


Element Name 


Direction Flow 


Required? 


Element Value 


Nested 
Element? 


TitleldCode 


ERS VODS 


Yes, if provided in the 
original retrofit 
request 


String 


No 


ECMData 


ERS -> VODS 


Yes 


Note: Can have more 
than one ECMData field 
per ECMRecord 


Yes 


MinDelay 


ERS -> VODS 


Yes 


Time (OO.sss) 


No 



Table 9 



[85] The TitleldCode element uniquely identifies a vendor specific title 
identification code that was supplied in the ECM request. ECMData contains new ECM 
information that is to be inserted into the message streams by VOD system 108. Each 
Message inside ECMData is spaced apart in time from the previous message by at least the 
amount of time specified by MinDelay. The format for MinDelay is the following: 
ss.sss 
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00.125 (i.e. 125 milliseconds) 

[86] The following table lists the elements of the ECMData element: 



Element Name 


Direction Flow 


Required? 


Element Value 


Nested 
Elements? 


Message 


ERS -» VODS 


Yes 


String containing 
Base64 encoded binary 
value 


No 


ProgramNumberOffset 


ERS ■> VODS 


Yes 


Integer 


No 



Table 10 

[87] "Message" is a string containing a Base64 (RFC1341) encoded 
binary value of ECM information. This binary value is to be Base64 decoded and inserted 
into the ECM PID of the MPEG message stream. Specifically, each individual ECM of the 
set returned in the ECMResponse is inserted into the appropriate location of the ECM PID. 
The ProgramNumberOffset is an offset, specified in bytes, into Message after which a 16- 
bit Program Number is overwritten. 



VOD system 108/ERS 104 Interface Protocol— Examples 
[88] Following are several examples of using VOD system 108/ERS 104 
Interface Protocol XML schema to generate valid XML documents suitable for transactions. 



al ERS 104 Synchronization Number Request — Example 

[89] It should be observed that only the id and password need to be sent in 
20 an ERSPayload to retrieve the ERSSynchNumber and CallbackDatetime. 
<?xml version="1.0" encoding- UTF-8'?> 

<ERSPayloadxmlns="http://www.motorola.com/namespaces/ERSPayload" 
xrmns:xsi="http://www.w3.org/1999/XMLSchema-instance'' 

xsi:schemaLocation=''http://www.motorola.corn/namespaces/ERSPayload ERSPayload.xsd" payloadld-' 1 "> 
25 <Verl.0> 

<Sender id="vods5323523" password-'VODPassword" role="vods"/> 
</Verl.0> 
</ERSPayload> 

Successful ERS 104 Transaction Response — Example 
30 This example is a typical ERS 104 transaction response. Note that the CallbackTime is specified as UTC. 

<?xml version="1.0" encoding='UTF-8'?> 

<ERSPayloadxmlns="http://www.motorola.com/namespaces/ERSPayload" 
xnibs:xsi=''http://www.w3.org/1999/XMLSchema-instance'' 

xsi:schemaLocation="http://www.motoro la.com/namespaces/ERSPayload ERSPayload.xsd" payloadld-' 1"> 
35 <Verl.0> 

<Sender id="l" password="n/a" role="ers"/> 
<ERSSynchNumber>25</ERSSynchNumber> 
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<CallbackTime>2000-07- 1 OTO 1 : 1 5 :OOZ</CallbackTime> 
</Verl.O> 
</ERSPayload> 

Successful ECM Request — Example 

[90] This example contains only one ECM request within the transaction, 
for one piece of content. However, multiple ECM requests may be made within a single 
ERSPayload. 



<?xml version="1.0" encoding='UTF-8'?> 

<ERSPayloadxmms="htip://www.motorola.com/namespaces/ERSPayload" 
1 0 xmlns:xsi="http://www.w3 .org/ 1 999/XMLSchema-instance" 

xsi:schemaLocation="http://www.motorola.coiri/namespaces/ERSPayloadERSPayload.xsd" payloadld-' 1"> 
<Verl.0> 

<Sender id="vods5323523" password="VODPassword" role="vods"/> 
<ECMRequest> 
1 5 <EncryptionRecord> 

<TitleIdCode>7820982</TitleIdCode> 
<ContentTitle>Top Gun</ContentTitle> 
<OLESId>83098224</OLESId> 
- <EncryptionTime>2000-07-02T 10:35:05 Z</EncryptionTime> 

720 <EncryptionMode>123</EncryptionMode> 
7 <Label>7<7Label> 

<EncryptedDataVersion>l</EncryptedDataVersion> 
<EncryptedDataBlock>j61wxup4NbeVu8nk=</EncryptedDataBlock> 
</EncryptionRecord> 
"'25 </ECMRequest> 
</Verl.0> 
</ERSPayload> 

Successful ECM Response — Example 
30 [91] This example is a typical response to the example request described 

in Section 0. 

<?xml veision="1.0" encoding='UTF-8'?> 

<ERSPayload xmlns="http://www .motorola.com/namespaces/ERSPayload" 
xmlns:xsi==''http://www.w3.org/1999/XMLSchema-instance'' 
35 xsi:schemaLocation="http://www.motorola.com/namespaces/ERSPayload 
http://www.motorola.com/namespaces/ERSPayload.xsd" payloadld-' 1 "> 
<Verl.0> 

<Sender id=" 1 " password="n/a" role="ers'7> 
<ECMRe sponse> 
40 <ECMRecord> 

<TitleIdCode>7820982</TitleIdCode> 

<MinDelay>200</MinDelay> 

<ECMData> 

<Message>kn8uVebN4puMtK0931wu5bVkj61xwvrkTlbn=</Message> 
45 <ProgramNumberOffset> 1 28</ProgramNumberOffset> 

</ECMData> 
<ECMData> 

<Message>rin8uVebN4puMtK0931wu5bVkj61xwvrkTlb6==</Message> 
<ProgramNumberOffset>128</ProgramNumberOffset> 
50 </ECMData> 
<ECMData> 

<Message>fn8uVebN4puMtM0931wu5bVkj61xwvrkTlb0=</Message> 
<ProgramNumberOffset>128</ProgramNumberOffset> 
</ECMData> 
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</ECMRecord> 
</ECMResponse> 

<ERSSynchNumber>26</ERSSynchNumber> 
<CallbackDatetime>2000-07-10T01:18:OOZ</CallbackDatetime> 
5 </Verl.O> 
</ERSPayload> 

ECM Request — Error Request Example 

[92] This example contains an ECM request within the transaction and is 
1 0 only intended to demonstrate an ERSPayload error with an invalid VODS Identifier. 
<?xml version="1.0" encoding='UTF-8'?> 

<ERSPayload xmlns="http://www.motorola.com/namespaces/ERSPayload" 
xmms:xsi- 'http://www.w3.org/1999/XMLSchema-mstance" 
xsi:schemaLocation="http://www.motorola.com/namespaces/ERSPayload 
15 http://www.motorola.com/namespaces/ERSPayload.xsd" payloadId="l"> 
<Verl.O> 

<Sender id="-1000" password="VODPassword" role="vods"/> 
<ECMRequest> 

<EncryptionRecord> 
r20 <TitleIdCode>7820982</TitleIdCode> 
= <ContentTitle>Top Gun</ContentTitle> 

- <OLESId>83098224</OLESId> 

<EncryptionTime>2000-07-02T10:35:05Z</EncryptionTime> 
<EncryptionMode> 1 23</EncryptionMode> 
- 25 <Label>7</Label> 

<EncryptedDataVersion>l </EnciyptedDataVersion> 
<EncryptedDataBlock>j61wxup4NbeVu8nk=</EncryptedDataBlock> 
</EncryptionRecord> 
</ECMRequest> 
30 </Verl.0> 
</ERSPayload> 

ECM Response (unsuccessful ECM Request) — Example 
[93] This example is a typical error response which in this case, the ERS 
35 1 04 determined that the VODSId was invalid. 
<?xml version-' 1.0" encoding- UTF-8'?> 

<ERSPayIoad xmlns="http://www.rnotorola.corn/namespaces/ERSPayload" 
xrnlns:xsi=''http://www.w3.org/1999/XMLSchema-instance" 
xsi:schemaLocation="http://www.motorola.corn/namespaces/ERSPayload 
40 http://www.motorola.com/namespaces/ERSPayload.xsd" payloadId="l "> 
<Verl.0> 

<Sender id=" 1 " password="n/a" role="ers"/> 
<ERSStatus statusNumber="1002" severity="error"> 

<GeneralStatusText> The VOD System identifier, -1000, submitted in the id attribute of the 
45 Sender element was not recognized by the ERS. 

</GeneralStatusText> 

<ExtendedStatusData>- 1 000</ExtendedStatusData> 
</ERSStatus> 
</Verl.0> 
50 </ERSPayload> 
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ECM Request — Error ECMRequest Example 



[94] This example contains an ECMRequest within the transaction and is 

intended to demonstrate a problem with the ECMRequest. 

<?xml version-' 1.0" encoding- UTF-8'?> 
5 <ERSPayload xmlns="http://www.motorola.com/namespaces/ERSPayload" 
xmlns:xsi="http://www. w3.org/1999/XMLSchema-instance" 
xsi.•schemaLocation="http://w'w^\^motorola.com/narnespaces/ERSPayload 
http://www.motorola.com/namespaces/ERSPayload.xsd" payloadId="l "> 
<Verl.O> 

1 0 <Sender id="vods5323523" password="VODPassword" role="vods"/> 

<ECMRequest> 

<EncryptionRecord> 

<TitleIdCode>7820982</TitleIdCode> 
<ContentTitle>TopGun</ContentTitle> 
15 <OLESId>7878</OLESId> 

<EncryptionTime>2000-07-02T10:35:05Z</EncryptionTime> 
<EncryptionMode> 1 23</EnciyptionMode> 
<Label>7</Label> 

<EncryptedD ataVersion> 1 </EncryptedData V ersion> 
.20 <EncryptedDataBlock>j61wxup4NbeVu8nk=</EncryptedDataBlock> 
;1 </EncryptionRecord> 
</ECMRequest> 
</Verl.()> 
3 </ERSPayload> 

25 

ECM Request — Invalid EncryptionData Example 

[95] This example contains only one ECM request within the transaction, 

~ for one piece of content. In this example, the ERS 104 has determined that the 

EncryptionData inside the EncryptionRecord is invalid. 

;' 30 <?xml version="l .0" encoding='UTF-8'?> 

<ERSPayload xrnlns==''http://'www.n^otorola.con^/narnespaces/ERSPayload , ' 
xmlns :xsi="http ://www.w3 .org/ 1 999/XMLSchema- instance" 
xsi:schemaLocation="http://www .motorola.com/namespaces/ERSPayload 
http://www.motorola.com/namespaces/ERSPayIoad.xsd" payloadId="l "> 
35 <Verl.O> 

<Sender id="vods5323523" password="VODPassword" role="vods"/> 
<ECMRequest> 

<EncryptionRecord> 

<TitleIdCode>7820982</TitleIdCode> 
40 <ContentTitle>Top Gun</ContentTitle> 

<OLESId>83098224</OLESId> 

<EncryptionTime>2000-07-02T10:35:05Z</EncryptionTime> 
<EncryptionMode> 1 23 </EncryptionMode> 
<Label>7</Label> 

45 <EncryptedDataVersion>l</EncryptedDataVersion> 

<EncryptedDataBlock>j61wxup4NbeVu8nk=</EncryptedDataBlock> 
</EncryptionRecord> 
</ECMRequest> 
</Verl.0> 
50 </ERSPayload> 
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Unsuccessful ECM Response — Invalid EncryptionData Example 

[96] This example is a typical error response to a request. In this case the 

ERS 104 has determined that the EncryptionData received in the request was invalid. 

<?xml version="1.0" encoding='UTF-8'?> 

<ERSPayload xmlns- 'http ://www.motorola.com/namespaces/ERSPayload" 
xmlns:xsi="http.7/www. w3.org/1999/XMLSchema-instance" 
xsi:schemaLocation="http://www.motorola.corn/namespaces/ERSPayload 
http://w\rw.motorola.corn/namespaces/ERSPayload.xsd'' payloadld-' 1 "> 
<Verl.0> 

<Sender id="l" password- 'n/a" role="ers"/> 
<ECMResponse> 

<TitleIdCode>7820982</TitleIdCode> 

<ERSStatus statusNumber="5003" severity="error"> 

<GeneralStarusText>The ERS has determined that the encryption data in the Encryption 
Record in the ECM Request was invalid. 

</GeneralStatusText> 
</ERSStatus> 
</ECMResponse> 

<ERSSynchNumber>26<ERSSynchNumber> 
<CallbackDatetime>2000-07-10T01 : 18:00Z</CallbackDatetime> 
</Verl.0> 
</ERSPayload> 

XML Schema - VODS/ERS 104 Interface Protocol 

<?xrnl version="1.0" encoding-' UTF-8"?> 

— al't with XML Spy v3.() NT (lHtp: www.xmkpy.com) at Motorola. Inc. --> 
-W3C Schema generated by XML Spy v3.0 NT (http: \\w\\.xmlspy.eom)--> 

— ; ' — > 

Copvrightf'c) 2001 Motorola. Inc. — > 
All Rights Reserved --> 

— / — > 

— I he following i epresent the content of transactions between the ERS arid VOD Systems — > 
> 

Protocol Versions currently supported: Verl .0 — > 

> 

<xsd:schema targetNamespacc="http://motorola.motacc.net/namespaces/ERSPayload" 
xmlns:xsd="http://www.w3.org/1999/XMLSchema" 
xmlns:ers="http://motorola.motacc.net/namespaces/ERSPayload"> 
<xsd:element name="ExtendedStatusData" type="xsd:string7> 
<xsd:element name="GeneralStatusText" type="xsd:string'7> 
<xsd:element name="ERSStatus"> 
<xsd:complexType> 
<xsd:sequence> 

<xsd:element ref="ers:GeneralStatusText"/> 
<xsd:element ref="ers:ExtendedStatusData" minOccurs="0"/> 
</xsd:sequence> 

<xsd:attribute name="statusNumber" type="xsd:integer" use=="required"/> 
<xsd:attribute name="severity" use="required"> 

<xsd:simpleType base="xsd:string" derivedBy="restriction"> 
<xsd: enumeration value="warning"/> 
<xsd: enumeration value="error"/> 
</xsd:simpleType> 
</xsd:attribute> 
</xsd:complexType> 
</xsd:element> 

<xsd:element nanie="TitleIdCode" type="xsd:string"/> 
<xsd:element name="ContentTitle" type="xsd:string"/> 
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<xsd:element name-'OLESId" typc="xsd:long"/> 
<xsd:element name="EncryptionTime" type="xsd:timeInstant"/> 
<xsd:element name="EncryptionMode" iype="xsd:integer"/> 
<xsd:element name-'Label" lype="xsd:integer"/> 
5 <xsd:element name="EncryptedDataVersion" type="xsd: integer "/> 

<xsd:annotation> 

<xsd:documentation> 

Note that EncryptedDataBlock below is a Base64 encoding of a binary value 
</xsd:documentation> 
1 0 </xsd:annotation> 

<xsd:element name- 'EncryptedDataBlock" tj'pe="xsd:string"/> 
<xsd:element name="EncryptionRecord"> 
<xsd:complexType> 
<xsd:sequence> 

15 <xsd:element ref="ers:TitleIdCode" minOccurs- '0"/> 

<xsd:element ref="ers:ContentTitle" minOccurs="0"/> 

<xsd:element ref="ers:OLESId"/> 

<xsd: element ref="ers : EncryptionTime "/> 

<xsd:element ref="ers:EncryptionMode"/> 
20 <xsd:element ref="ers:Label"/> 

<xsd: element ref="ers:EncryptedDataVersion"/> 

<xsd: element ref="ers:EncryptedDataBlock"/> 
^ </xsd:sequence> 
Z </xsd:complexType> 
25 </xsd:element> 
<xsd:annotation> 

<xsd:documentation> 

[97] Message is a string containing a Base64 (RFC1341) encoded binary 
value of ECM information. This binary value will need to be Base64 decoded and inserted 
30 into the ECM PID of the MPEG message stream. Specifically, each individual ECM of the 
set returned in the ECMResponse must be inserted into the appropriate location of the ECM 
PID. 

</xsd:documentation> 
</xsd:annotation> 
35 <xsd:element name="Message" type- 'xsd:string"/> 

<xsd:element name="ProgramNumberOffset" typc="xsd:integer"/> 
<xsd:element name="ECMData"> 
<xsd: complexType> 
<xsd:sequence> 
40 <xsd:element ref="ers:Message"/> 

<xsd:elementref="ers:ProgramNumberOffset"/> 
</xsd:sequence> 
</xsd: complexType> 
</xsd:element> 

45 <xsd:element name=''MinDelay" t\ r pe="xsd:integer"/> 

<xsd:element name="ECMRecord"> 
<xsd:complexType> 
<xsd:annotation> 

<xsd:documentation>MinDelay is the number of milliseconds</xsd:documentation> 
50 </xsd:annotation> 
<xsd:sequence> 

<xsd:element ref="ers:TitleHCode" minOccurs="0"/> 
<xsd:element ref="ers :MinDelay'7> 

<xsd:element ref="ers:ECMData" maxOccurs="unbounded"/> 
55 </xsd:sequence> 
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</xsd: complexType> 
</xsd:element> 

<xsd:element name="ECMRequest"> 
<xsd:complexType> 
5 <xsd:sequence> 

<xsd:element ref="ers:EncryptionRecord'V> 
</xsd:sequence> 
</xsd:complexType> 
</xsd:element> 
10 <xsd:group name="goodResp"> 

<xsd:sequence> 

<xsd:elementref="ers:ECMRecord"/> 

<xsd:element ref="ers:ERSStatus" minOccurs="0" maxOccurs="unbounded"/> 
</xsd:sequence> 
1 5 </xsd:group> 

<xsd:element name="ECMResponse"> 
<xsd:complexType> 
<xsd:choice> 

<xsd:sequence> 

20 <xsd:element ref="ers:TitleIdCode" minOccurs="0"/> 

<xsd: element ref="ers:ERSStatus" minOccurs="0" maxOccurs="unbounded"/> 
</xsd:sequence> 

<xsd:group i-ef="ers:goodResp"/> 
- </xsd:clioice> 
"25 </xsd:complexType> 
S </xsd:element> 

<xsd:element name="Sender"> 

<xsd:complexType eontent="empty"> 

<xsd:attribute name="id" type="xsd:string" use="required"/> 
•30 <xsd: attribute name="password" type="xsd: string" use="required"/> 

<xsd:attribute name="role" use="required"> 
Z, <xsd:simpleType base- 'xsd: string 1 ' derivedBy="restriction"> 

<xsd:enumeration value- Vods7> 
^ <xsd: enumeration value="ers"/> 

35 </xsd:simpleType> 

</xsd:attribute> 
7 </xsd:complexType> 
</xsd:element> 

<xsd:group name="respGroup"> 
40 <xsd:sequence> 

<xsd:element ref="ers:ECMResponse" minOccurs="0" maxOcciiTS="8"/> 
<xsd:element name="ERSSynchNumber" iype="xsd:unsignedByte" minOccurs="0"/> 
<xsd:element name="CallbackTime" type="xsd:timelnstant" minOccurs="0"/> 
<xsd:element ref="ers:ERSStatus" minOccurs="0" maxOccurs="unbounded"/> 
45 </xsd:sequence> 
</xsd:group> 

<xsd: element name="Verl.O"> 
<xsd: complexType> 
<xsd:annotation> 
50 <xsd:documentation> 



[98] The following are the particles of ERSPayload under Ver 1 .0 and their 

requirements: 

[99] The Sender element has no particle children but has 3 attributes: id - 
55 identifier for the sending system password - corresponds to the id of the sending system, 
and role - this indicates "who" the sender is. this can either be only "vods" or "ers". The 
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ECMRequest element contains a single request for a new ECM. One or more 
ECMRequests can be made per payload. The ECMResponse is analogous to the 
ECMRequest element in that it contains a single retrofitted ECM that corresponds to the 
original request. There can be up to 8 ECMResponses per payload. The ERSSynchNumber 
5 contains the most recent synchronization number from the ERS that corresponds to the 
requesting VOD System. The CallbackTime contains the next callback time that is 
uniquely assigned by the ERS for a particular VOD System. There cannot be ECMRequests 
and ECMResponses in the payload simultaneously. 

[100] ERS Status contains error code responses from the ERS to VOD 

10 Systems. The particles of this element contain other elements that will give additional 
descriptive information describing the nature of the problem. Elements: 
GeneralStatusText - A short text summary that is uniquely associated with the 
statusNumber attribute. ExtendedStatusData - Optional element that contains the erroneous 
item relating to the status number given in attribute statusNumber. The ERS Status tag has 

1 5 two attributes that are used for defining the exact reply status. They are: StatusNumber - 

A pre-defined four digit code assigned by the ERS. Four digits were chosen instead of 
three so that there would be no confusion between typical three digit HTTP response codes 
and codes defined by this protocol. 

[101] Severity - This attribute can have one of two possible values; 

_20 Warning - a warning Indicates that something went wrong although ECM retrofits may 

I have been successful. A full description of what went wrong will be provided in the 

GeneralStatusText element. An example of a warning may be an indication that an OLES is 
no longer defined and has become disassociated with the ERS. Error - Indicates a problem 
where an operation could not be completed. For example, a severe error would be 

25 the inability of the ERS to perform an ECM retrofit because supplied input 

information was either incorrect, incomplete, or corrupt. Note that ERSStatus may not be 

included in payload responses when the entire transaction is successful. 

</xsd:documentation> 
</xsd: annotation> 
30 <xsd:sequence> 

<xsd:element ref="ers:Sender"/> 
<xsd:choice> 

<xsd:element ref="ers:ECMRequest" maxOccurs="8"/> 
<xsd:group ref="ers:respGroup"/> 
35 </xsd:choice> 
</xsd:sequence> 
</xsd: complexType> 
</xsd:element> 

<xsd: element name="Ver2.0"> 
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<xsd:complexType> 
<xsd:sequence> 

<xsd:element ref="ers:Sender"/> 
</xsd: sequence> 
</xsd: complexType> 
</xsd:element> 

<xsd:element name="ERSPayload"> 
<xsd:complexType> 
<xsd:annotation> 

<xsd : documentation 



The ERSPayload supports several protocol versions through the use of particle children of the 
ERSPayload element. Currently, Verl.O is the only protocol version that is supported. The 
following are the attributes for the ERSPayload element: 

1 5 payloadld - Attribute that is optionally used by VOD Systems to track payload 

requests/responses. 

schemaLocation - This attribute is relevant to checking the validity of the document content, on 
a namespace by namespace basis. It contains pairs of values: The first member of each pair is 
20 the namespace for which the second member is the hint describing where to find to an 

appropriate schema document. The presence of these hints does not require the processor to 
obtain or use the cited schema documents, and the processor is free to use other schemas 
obtained by any suitable means, or to use no schema at all. 

25 NOTE: The Ver2.0 protocol version control element is included below for demonstration 

purposes to show future authors of this protocol where/how to begin writing the next protocol 
revision. It should be noted, however, that Ver2.0 is merely a place holder and could be 
changed to the next logical protocol version following Verl .0 (e.g. Ver 1_1_2). 

30 </xsd: documentation 

</xsd:annotation> 
<xsd:choice> 

<xsd:element ref="ers: Verl .0" mmOccurs="07> 
<xsd: element ref="ers:Ver2.0" mmOccurs="0"/> 
.35 </xsd:choice> 

<xsd:attribute name="payloadId" type- 'xsd:string" use="optional"/> 
<xsd: attribute name="schemaLocation" type="xsd:uriReference" use="default" 
value- Titrp://motorola.motacc.net/namespaces/ERSPayload 
http://motorola.motacc.net/namespaces/ERSPayload.xsd"/> 
40 <xsd: attribute name="xmlns" type- 'xsd:uriReference" use-'default" 

value= , 'http://motorola.motacc.net/namespaces/ERSPayload"/> 
<xsd: attribute name="xsi" type="xsd:uriReference" 
value="http://www.w3 .org/ 1 999/XMLSchema-instance"/> 
</xsd:complexType> 
45 </xsd:element> 
</xsd:schema> 

[102] While the above is a complete description of exemplary specific 
embodiments of the invention, additional embodiments are also possible. Thus, the above 
50 description should not be taken as limiting the scope of the invention, which is defined by 
the appended claims along with their full scope of equivalents. 
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